XML-Based Import / Export

XML documents have been broadly adopted as a standard format for information interchange. In that standard the parties agree on a set of XML schemas that specify the semantic contents of otherwise meaningless syntactic constructions. One of the advantages of this approach is that the parties can publish the schemas without being forced to disclose confidential details about the structure of their inner objects. In addition, this encapsulation property, frees the developers from the need to consider foreign codifications, and let them concentrate on the actual data under transference. This document describes a foundational set of XML schemas that PetroVR commits to support and maintain for the reading and writing of XML documents.

Introduction

For the sake of brevity, this document has been restricted to include only the specifications of Fluids and Units. Since all the XML schemas used in this project follow the patterns and considerations described here, those schemas are made available on request.

Several considerations have been evaluated before defining the schemas. In this section we summarize the main ones.

Simplicity

The parts have agreed in keeping the initial approach as simple as possible. At the same time, they have established the minimum set of data that must be transferred in XML sentences. In consequence, the XML schemas we present here were carefully designed as to achieve a good balance between generality and simplicity. To our understanding, schemas trying to foresee too many extensions would, most likely, have added unwanted complexity to the definitions. On the other side, too simplistic schemas would have resulted insufficient for actual data interchange.

Advantages of the Approach

The developers found that the proposed approach has some few advantages that we enlist here

• [Time saving] XML greatly simplifies the work of programmers by freeing them from "reinventing the wheel." Instead of being forced to write (anddebug) ad hoc routines that interpret non-standard formats, programmers can make use of a broad variety of available XML parsers.
• [Flexibility] XML is flexible enough as to contemplate the widest range of applications, from the simplest ones to the more sophisticated.
• [Confidentiality] XML schemas allow end-users to share a diversity of data without disclosing the inner structure of presumably confidential objects. Since there is no mandatory relation between the schemas and the internal object model of the applications, they reveal no additional details on the way the XML data is stored or processed.
• [Validation] XML documents can be validated very simply by feeding them in any XML parser, and verifying that they meet the agreed formats. That provides an impartial way to elucidate whether the data exported by each of the parts is well formed.
• [Reusability] The XML schemas developed here, as well as the infrastructure developed for this project, can be reused in the future in other projects or under different circumstances (e.g. importing/exporting data from/to other sources).

XML Standards

The schemas and XML documents (a.k.a. instances) presented here follow the W3C Recommendation 28 October 2004. We refer the reader to http://www.w3.org for additional material.

Oil Industry Standards

Even though several organizations of the oil industry have proposed many schemas, the three parties involved in the XML-link project found those schemas too distant in scope and spirit from the ones required in their case. Thus, instead of embarking in a complicated discussion on which would be the most compatible and formal schema model to adhere to, the parties agreed in creating an initial set of simple schemas from scratch.

Namespaces

XML-based projects are usually made up of several schemas, called modules. The more general approach would consist in defining as many XML namespaces as modules are. However, in its first phase the present project avoids creating namespaces for the sake of simplicity.

Element Names

It has been assumed that all the data items to be transferred have well known names that belong to the domain language spoken by end-users. Hence, the selection of XML names has tried to follow the usual nomenclature. For instance, the parameters that describe a concrete Oil fluid are

Units

In the initial phase the project restricted itself to units in the Oil Field. For instance, all GOR quantities will be expressed in scf/bbl (or scf/bbl), and not in the Metric System. This restriction could be removed in the future if required.

Another important decision regarding units is that all measures do explicitly include their units in the XML statements. While implicit units would have saved some space, XML documents are supposed to be as self-documented as possible. The only exceptions to this rule are the quantities that are known to have no units.

Initial Examples

To get started we illustrate our approach with the contents of three instance documents.

Water example:

<WaterFluid>

<Name>Sample Water</Name>

<Bw>1.0</Bw>

</WaterFluid>

Here, the Bw tag represents the water formation volume factor of this Sample Water. Note that there is no unit associated to this quantity.

Oil example:

<OilFluid>

<Name>Permian Oil</Name>

<Bo>1.2</Bo>

<InitialGOR unit="scf/bbl">500.0</InitialGOR>

<Gravity unit="API">20.0</Gravity>

</OilFluid>

The Oil example shows units expressed as attributes. For instance, the InitialGOR tag specifies the "scf/bbl" unit as the value of its unit attribute.

Associated Gas example:

<GasFluid>

<Name>Associated Gas</Name>

<Gravity>0.8</Gravity>

<CalorificValue unit="BTU/scf">1000.0</CalorificValue>

</GasFluid>

Free Gas example:

<GasFluid>

<Name>Free Gas</Name>

<Gravity>0.8</Gravity>

<CalorificValue unit="BTU/scf">1000.0</CalorificValue>

<CorrelationType>Wet</CorrelationType>

<OilYield unit="bbl / MM scf">50.0</OilYield>

<WaterYield unit="bbl / MM scf">10.0</WaterYield>

</GasFluid>

The Free Gas example illustrates one of our enumerated values, the CorrelationType. The value of this element can be Wet or Dry.

The XML Modules

In this section we present the schemas corresponding to the examples depicted above.

As usual, all the schemas will repeat the required heading and footing lines:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

< !--- some statements here --- >

</xsd:schema>

Note how the lack of namespaces simplifies the headers.

In what follows we will omit these lines for the sake of simplicity.

All modules use the filename extension .xsd as usual.

The Water Fluid Module

The schema corresponding to the Water example is as follows:

<xsd:element name="WaterFluid" type="water-fluid-type"/>

<xsd:complexType name="water-fluid-type">

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Bw" type="xsd:decimal"/>

</xsd:sequence>

</xsd:complexType>

The Water Fluid schema shows the notational conventions we have adopted. Complex types start in upper case, as in WaterFluid, and use upper and lower case characters to separate their component words. Type names, on the other hand, use dash-separated lowercase terms, as in water-fluid-type. For the sake of uniformity, all type names end up with type.

As explained above, the full contents of the WaterFluid.xsd file consists in the lines printed above, plus the heading and footing that open and close the <xsd:schema> tag.

The Oil Fluid Module

This module makes use of the Units module (explained below) by including it as shown in the first line.

<xsd:include schemaLocation="Units.xsd"/>

<xsd:element name="OilFluid" type="oil-fluid-type"/>

<xsd:complexType name="oil-fluid-type">

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Bo" type="xsd:decimal"/>

<xsd:element name="InitialGOR" type="gor-type"/>

<xsd:element name="Gravity" type="oil-gravity-type"/>

</xsd:sequence>

</xsd:complexType>

The Gas Module

The module for the simplest associated gas would be as follows:

<xsd:include schemaLocation="Units.xsd"/>

<xsd:element name="GasFluid" type="gas-fluid-type"/>

<xsd:complexType name="gas-fluid-type">

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Gravity" type="xsd:decimal"/>

<xsd:element name="CalorificValue" type="calorific-value-type"/>

</xsd:sequence>

</xsd:complexType>

However, since free gasses require additional elements as shown in the Free Gas example above, we must add those elements as optional (minOccurs="0").

<xsd:include schemaLocation="Units.xsd"/>

<xsd:element name="GasFluid" type="gas-fluid-type"/>

<xsd:complexType name="gas-fluid-type">

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Gravity" type="xsd:decimal"/>

<xsd:element name="CalorificValue" type="calorific-value-type"/>

<xsd:element name="CorrelationType" type="correlation-type-type" minOccurs="0"/>

<xsd:element name="OilYield" type="yield-type" minOccurs="0"/>

<xsd:element name="WaterYield" type="yield-type" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

The Units Module

All quantities requiring units are defined following the same pattern. That pattern consists in extending the simple type xsd:decimal with the unit attribute. As we will see, there are also some few enumerated types.

The calorific-value-type is defined as follows:

<xsd:complexType name="calorific-value-type">

<xsd:simpleContent>

<xsd:extension base ="xsd:decimal">

<xsd:attribute name="unit" type="xsd:string" use="required" fixed="BTU/scf"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

Exactly the same pattern is used for the gor-type:

<xsd:complexType name="gor-type">

<xsd:simpleContent>

<xsd:extension base ="xsd:decimal">

<xsd:attribute name="unit" type="xsd:string" use="required" fixed="scf/bbl"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

Same for yield-type:

<xsd:complexType name="yield-type">

<xsd:simpleContent>

<xsd:extension base ="xsd:decimal">

<xsd:attribute name="unit" type="xsd:string" use="required" fixed="bbl / MM scf"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

The correlation-type-type is an example of an enumerated type:

<xsd:simpleType name="correlation-type-type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="Wet"/>

<xsd:enumeration value="Dry"/>

</xsd:restriction>

</xsd:simpleType>

Conclusions

The schemas introduced here are the outcome of a process that begun with the identification of an initial set of data items and parameters. The next step was the creation of sample instance documents (.xml files) that reflected the original intend. Finally, the instance documents were formalized into their corresponding XML schemas.

The modularization we have adopted makes no use of namespaces for the sake of simplicity. It consists on a set of simple schemas for the basic data types: Fluids, Facilities, Reservoirs, Wells and Pipelines. An additional schema enlists the Units required by the modules.

While we have not included all the modules, this document illustrates the main lineaments of the overall approach. It also establishes the notation and nomenclature, and can be considered as the starting point for further discussion and enhancements.